Web browsers are becoming more and more important as application platforms across all kinds of equipment; computers, pads, smartphones, etc. However, much of the functionality required by applications is provided by third party plug-ins. The functionality provided by the plug-ins is crucial to many successful web applications existing today. Examples of plug-ins include ADOBE FLASH and MICROSOFT SILVERLIGHT.
Nevertheless, plug-ins are also a source of problems, both in terms of security and usability and the upcoming fifth revision of the HyperText Markup Language standard (HTML5) is therefore aimed at eliminating (or at least reduce) the need for third party plug-ins. One area where plug-ins are required today is video conferencing, and HTML5 therefore addresses this use case with a set of appropriate application programming interfaces (APIs) that will provide camera and microphone access to web apps.
Devices with advanced browser implementations enable access to functionality able to expose more personal (and thus sensitive) user data such as recordings via a video camera, audio via a microphone and even sensors for biometric data such as heart beat and blood pressure. It goes without saying that it has been seen as vital to also manage and control the access to such sensitive data in order to not lose the trust and confidence of end users that are using browsers.
However the need to protect the end-user also has a clear impact on implementations of devices and browsers and many service providers see this as a business opportunity in itself. Standards work has been proposed to introduce access control to APIs that operate as a front for accessing sensitive user data resources but not without complications. Existing solutions, and the relevant parts of the suggested HTML5 standards, are based on a security/privacy concept where the user is prompted with a modal dialog on each request from a web application or a web site that requests access to devices like the camera, microphone, location data provider, etc.
As an example, access to a camera is given to a web application in response to the JavaScript API getUserMedia (“video”, callback). First the user is prompted for device access, and can select from the available devices in a modal dialog. The video stream is returned in the callback to the web application and dispatched when the modal dialog is dismissed.
The problem with a modal dialog is two-fold: first, modal dialogs tend to annoy the user since all execution is stopped until the user has acknowledged the dialog by granting or denying access. Many users therefore get in the habit of just “OK”-ing all modal dialogs immediately on sight without reflecting over the consequences of granting access. Secondly, once access is granted or denied, there is no way for the user to, at a later point in time, get an overview of what devices a web application or web page has been granted or denied access to, or change the way in which devices are accessed.
Attempts have been made in the standardization work to provide a more explicit access control mechanism as part of the application layer/APIs. However, these suggested mechanisms have not been accepted by all involved parties, typically due to the impact on implementations adding cost and reducing flexibility on the design relating to user-experience. Consequently these attempts have failed and any attempts to define a standards based explicit access control have been stopped in its tracks.